Access to the Internet and to other computers has greatly increased the exposure of computers to software components of unknown and uncontrolled origin. When executed, these components from potentially untrusted sources may violate site-specific policies relating to security and access control. It is therefore important to provide a mechanism for handling the execution of such software components without unduly restricting their functionality.
Dynamically linked libraries, Java applets, and Active-X controls are good examples of software components that are widely used in modem computer systems and which often do not originate on a local, trusted computer, but instead are downloaded over a wide area network, or as it even more frequently the case, over the Internet. Typically, these software components execute only with the security services that are native to the particular software component system or the operating system that hosts the software components. However, the conventional environment or operating system in which these components are executed typically does not provide adequate security services for enforcing security on tightly integrated software components. For example, Active-X controls currently have no security constraints enforced upon them and normally execute with the same privileges as the program that loaded them.
While some component systems may allow a programmer to integrate fine-grained security enforcement into a software component while the component is being developed, it is generally not possible to access the component's source code to make changes to the security features at the site where the software component is later actually being used. Such changes may be particularly important if the security policy at the site where the component is used is substantially incompatible with that originally programmed into the component. However, the prior art does not provide any practical technique for making changes to the security policy implemented in such a component.
It would clearly be desirable to provide security administrators with a mechanism allowing them to control and observe the behavior of software components derived from a different source in regard to security and access issues. The control and observation of these components should thus be independent of the origin of the component, and independent of the security services of the hosting component system or operating system used to execute the software component. Further, it would be desirable for this mechanism to interpose access control checks, protection domain transfers, and auditing onto software component operations in a transparent manner that does not otherwise affect the functionality and execution of the software components. The auditing may encompass instrumenting the software components to provide information relating to the execution of the component as thus modified. Such information might provide an indication of the efficiency of the software component in completing a function, or the processor overhead that the software component creates, or indicate the number of times that it calls a routine, etc. The mechanism providing these functions should also separate the enforcement and auditing of the security policy from the actual site-specific security policy. By doing so, the approach should be appropriate for use in environments that rely on potentially insecure software components, as well as for use in environments in which security policies frequently change.